The COBOL programming language defines a binary coded decimal data type, which encodes each decimal digit in binary form as a separate character. The traditional decimal data type has been the "unpacked", or ASCII, form, wherein commonly eight bits are used to represent each decimal digit: four bits to hold the value of the digit, and the other four bits to hold a code identifying the character as representing a digit.
This form of the decimal data type is inefficient. It consumes eight bits to hold only a four-bit value, and hence is wasteful of memory. The large number of bits that must be moved each time a digit is moved inside a processor also adversely impacts system performance. To avoid such inefficiency, a "packed" form of the decimal data type had subsequently been developed, which discards the code-holding bits and merely retains the four value-holding bits of the "unpacked" form. The "packed" form is also known as the "binary-coded decimal", or BCD, form; "packed" is often used to refer to signed BCD, whereas BCD is typically considered to be unsigned, i.e., a magnitude.
Because most digital computers are binary computers that perform binary, as opposed to decimal, operations, it has conventionally been necessary to convert decimal data into binary data before processing, such as arithmetic operations, could be performed on that data on most computers. But the conversion is time-consuming and impacts adversely system performance. A scheme was developed that allowed arithmetic operations to be performed on the unpacked decimal digits without conversion. But this scheme required the presence of the code-holding bits for bit-manipulation and temporary storage purposes. Hence, it is not usable with the packed decimal form.
The prior art has attempted to develop a scheme that would allow processing of packed decimal digits directly, without conversion to either the unpacked decimal or binary form. The results have been disappointing. The scheme requires that special hardware be present in a computer for its support. Hence, the scheme is not suited for use on general purpose computers that do not provide that special hardware support. Furthermore, the scheme is cumbersome and inefficient, and thereby negates in large measure the benefits of improved system performance that were sought to be achieved thereby.
Computers have also been developed that provide full hardware support in their arithmetic and logic units for both decimal and binary processing. However, such computers effectively provide separate arithmetic and logic units for the decimal and binary data types. Such duplication is very expensive. And attempts at avoiding complete duplication of arithmetic and logic unit hardware by sharing hardware components between the units introduce undesirable performance-robbing delays into the operation of the arithmetic and logic units.
In summary, then, problems in the art are the lack of a scheme for processing packed decimal data directly, without need for conversion to a different data type, on computers providing no special hardware support therefor, and the lack of a hardware-supported scheme for directly processing packed decimal data that is efficient in terms of both cost and performance.